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DNSCurve will save the day 

Bernstein said that time on breakable 

DNSSEC offers "a patches," Bernstein said, 

surprisingly law level of He called for development 

security" -while causing of DNSSEC alternatives 

severe problems for DNS that quickly and securely 
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COMPREHENSIVE COM 3 J"ER SECURflY SERVICES 



*§. 



Two phase deployment 



First release a generic fix for the Kaminsky i 
attack that does not leak information to 
the bad guys (source port randomization) 

Then release the bug and patches 
specifically against the Kaminsky attack 
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*§. 



DNS query packet 



IP header containing Source IP and Dest IP 



UDP or TCP Header containing 

Source Port and Dest Port 

(if TCP, also random Sequence Number) 

DNS Query ID 
DNS Query 
Option flags 



] 
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*§. 



DNS query example 



12.110.110.204 



193.110. 157. 13f 




DNS Query ID: 54321 

DNS Question: www.ripe.net? 

Option flags: RD 
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*§. 



DNS An swer packet 

12.110.110.204 



193.110.157.136 



UDP:53 



12345 



QUESTION SECTION 
Query ID: 54321 
Question: www.ripe.net? 



ANSWER SECTION 



AUTHORITY SECTION 

ripe.net NS ns-pri. ripe. net. (ttl = 172800) 

ripe.net NS ns-ext. isc.org. (ttl = 172800) 

ADDITIONAL SECTION 

ns-pri. ripe. net A 193.0.0.195 (ttl = . 

ns-pri. ripe. net AAAA 2001:610:240:0:53:3 
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^'xelerance 

- TXID 



is not enough anymore 



'Bellowin's (theoretical) attack (1995) 



4 



Q:google.com 
► 



Na 

A:1.2.3.4 

src port: 53 

TXID: 15824 

Al.2.3.4 

src port: 53 

TXID: 37563 



erver 




Q:google.com 

src port: 53 

TXID: 12963 



A:1.2.3.4 

src port: 53 

TXID: 23221 



EVIL 
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nsl.google.com 



•§. 



* 



Losing the race 






ISPNS EVIL 

- Q:www. rbc.com ? 



RBCNS 



Q: www. rbc.com ? 7a ID = 32768 



A: www.rbc.com = 1.2.3.4; TXID = 00001 
i A: www.rbc.com = 1 .2.3.4 ; TXID = 00002 



A: www.rbc.com = 1.2.3.4; TXID = 00003 



A: WWW.rbC.com = 142.254.1 .143 ; TXID = 32768 



A: www.rbc.com = 
142.254.1.143 



TTL=86400 



TIME 
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•§. 



Winning the race 



4 I 

Fnrilkpr lOr NO 




EVIL 




RBCNS 





Q:www. rtDC.com ? 




Q:www. rbccom ? ^ 






A: www.rbc.com = 
1.2.3.4 




1.2.3.4 
A: www.rbc.com = 




1.2.3.4 A: www.rbc.com = 
142.254.1.143 





TIME 



A: www. rbccom = 
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^xelerance 

Random source ports 

. Bernstein:llse random src ports as entropy 



4 



Q:google.com 



Na 

A:1.2.3.4 
src port: 2220 
TXID: 15824 



A:1.2.3.4 
src port: 2221* 
TXID: 37563 



erver 




Q:google.com 
src port: 8573 
TXID: 12963 




Al.2.3.4 
src port: 2222 
TXID: 23221 



nsl.google.com 



EVIL 
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UB's hack is still just a hack 



Q:www.rbc.com 
TXID:32768 

SRCPORT:54195 




Q:www.rbc.com 
TXID:32768 
ORT:1025 
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irthday Attack on src ports 



♦ 



EVIL 



Q:google.com 

Q:google.com 

Naj 

A:1.2.3.4 
src port: 2220 
TXID: 4524 



A:1.2.3.4 
src port: 2221* 
TXID: 4524 



erven 




Q:google.com 
src port: 14773 
TXID: 49265 

Q:google.com 
src port: 8573 
TXID: 12963 

Q:google.com 
src port: 2222 
TXID: 4524 



A:1.2.3.4 
-re port: 2222 
TXID: 4524 




nsl.google.com 



EVIL 
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ice 

NAT and DNS rebinding 

%"^ Qwww.rbc.com ffl 

5 — * l> 



Q:www.rbc.com 
TXID:32768 

SRCPORT:54195 



i 



EndUser 



Nameserver NAT / Firewall 



Q:www.rbc.com 

TXID:32768 
3Rt>PORT:1025 
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IAT and DNS rebinding (2) 



10.1.1.2 



10.1.1.3 



te 



Q: www. evil, com 
► 




A:10.1.1.3 

EndUser Nameserver ^ JiAJ / Firewall 



evil.com 
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•f-Kasphureffs attack (1997) 
caused Bailywick restrictions 



QUESTION SECTION 
Query ID: 54321 
Question: www.ripe.net? 

ANSWER SECTION 





AUTHORITY SECTION 
ripe.net NS ns-pri. ripe. net 
ripe.net NS ns-ext.isc.on 

ADDITIONAL SECTION 



(ttl=FOREVER) 
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What protected our DNS? 



'The attacker cannot see your packet 
You always lose at StarBucks and TOR 

transaction ID (TXID) 
Time To Live (TTL) 
Bailywick 
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*§. 



The Kaminsky Attack 



QUESTION SECTION 

Query ID: 54321 

Question: bogusl2345.www.paypal.com 

ANSWER SECTION 



AUTHORITY SECTION 
bogusl2345.www.paypal.com NS 
www.paypal.com 



If you lose the race, 
try bogusl2346 



ADDITIONAL SECTION 
www.paypal.com A 1.2.3.4 



Overrides cache 



Without source port randomization, this 
only takes about 65535 packets 
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•§— DNS related issues: 
Double Fast Flux 

Botnets use domains with NS and A 
records with low (eg 3 minute) TTL's 

Change NS records via Registrar very 
quickly too (hours) 

This makes them next to impossible to 
shutdown. 



(and soon OpenDNS commercial double fast flux) 
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•2— DNS related issues: 
|j The Wifi hotspot 

■Captive portals using DNS with mini DNS 



"server" 



This is so they can serve fake DNS 

■ 

■This can cause client to cache wrong DNS 

1 Bad implementations break on EDNS and 
DNSSEC (hardcoded bits checking) 



iMJse transparent IP proxy instead 
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■ xele 



Where to fix the DNS ? 
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^xelerance 

i: DNS is critical infrastructure 

1 Backwards compatible (opt-in) 

Non-invasive or intrusive (drop-in) 
. Non-disruptive (no CPU/Bandwidth hog) 
' No Protocol changes(we have DNSSEC) 
, Preferably no TYPE overloading 

No magic such as untested cryptography 
, Patent / Royalty free 
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Thou Shalt Implement: 



BCP38 



(Egress Filtering) 
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«§. 



Thou Shalt not: 

combine a 

recursive and 

authoritative 

server 
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Authorative nameservers 



Upgrade server to allow DNSSEC 
Diversify your infrastructure 



u 



<o> DiG 9. 6. Sal <o> -t ns xelerance.com 
;; global options: printcmd 
; j Got answer: 

;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 57177 
;; flags: qr rd raj QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 



ANSWER SECTION: 
xelerance.com. 
xelerance.com. 
xelerance.com. 

;; ADDITIONAL SECTION: 

nsO.xelerance.nl. 

nsl.xelerance.net, 



WHEN: Sat Ian 31 12:05:29 2009 
MSG SIZE rcvd: 142 



ns2, xelerance.org. 
nsO.xelerance.nl. 
nsl.xelerance.net. 



lack Hat Briefin 



•§■ 



Network IDS / Firewall 



It's patch work (pun intended) 

Does not address the problems 

Cannot make a decision when an attack is 
detected. What to do? Blocking is bad 
(denial of service to yourself) 



Monitor, log and warn. Do not interfere 
Be very careful with DNS load balancers 
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Monitor Unix based DNS 



Unbound DNS answers by return code - by week 



LjJll^J>Su>t|J^ 



25 26 27 28 29 30 31 



□ NOERROR 

■ SERVFAIL 

■ II I - 'II I II 



nswer bogus 

urn rrsets marked bogus 



Cur: 
639.17m 
107.65m 
527.49m 
76.60m 
25.50m 
71.15m 
13.E7m 



Hin: 
224.19m 

21.70m 

223.40m 

7.75m 

0.00 

17.68m 
0.00 



1.50 
219.53m 

1.09 
184.85m 

6.86m 
159.57m 
26.87m 



Max: 
24.27 
6.22 
13.00 
3.37 
776.15m 
6.18 
445.53m 



Last update: Sun Feb 1 11:10:03 2009 
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Monitoring using Cisco 

www.cisco.com/web/about/security/intelligence/dns-bcp.htm 



Z policy-map type inspect dns preset_dns_map 

parameters 

!— TXID matching - allow only 1 response 
dns-guard 

id-randomization 

id-mismatch count 10 duration 2 action log 

11 message length max i mum 512 

match header-flag RD 

drop 
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Monitoring using Cisco 

firewall# show service-policy inspect dns 

■ Global policy: 

t Service-policy: global_policy 

Class-map: inspection_default 

B Inspect: dns preset_dns_map, packet 37841, drop 0, 

jeset-drop 

mossago l ongth max i mum 512, drop 

dns-guard, count 21691 

protocol-enforcement, drop 

nat-rewrite, count 

id-randomization, count 21856 

id-mismatch count 10 duration 2, log 2 
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•§. 



Application fixes 



So many different applications to fix 

DNS API for applications is poor 

Easy to fool: DNS Rebinding or Fast Flux 

But let's not build DNS recursive 
nameservers in every application 

(however a good recursive dns server on each host is 
a good solution) 
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•§— The inevitable: 

Fix recursive nameservers 

Port randomization 

Sanitize TTL's 

Use more IP addresses per DNS server 

Harden against bogus size packets 

Harden glue 

Additional queries for infrastructure data 

0x20 
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•§■ 



Birthday Attack protection 



'Do not allow multiple queries for the same 
question to be outstanding (AKA query 
chaining) 

■ 
■ 

Unbound, Bind and PowerDNS 
implement this properly 

dnscache from DJB was apparently 
vulnerable to this until a few days ago! 
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*§. 



Rebinding protection 



'Allow to specify IP addresses that may 
never appear in "external" domain 
names 

■ 
■ 

This way you can ensure 10.1.1.0/24 

would never come in through DNS 

rebinding. 

(supported in Unbound and PowerDNS) 
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Attacks can be detected 



auth ns 



cache ns 
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*§. 



Attack response #1 



B At a spoof detection threshold, ignore all 
answers for that query 

Prevents accepting the right forged answer ' 

■ Also prevents accepting the real answer 
," spoofmax=? 

, Small value : easy DOS 

i 

Large value: might be too late 
(PowerDNS has spoofmax=20) 
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*§. 



Attack response #2 



At a spoof detection threshold throw away 
the entire cache and start from scratch 

Prevents using an accepted forged answer 

Small value : easy DOS on the cache 

Large value: might be too late 
(Unbound has spoofmax=10M) 
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*§. 



Chain your caches |j 

„ (esp. the ones behind NAT) ~ 
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Add more NS records? 



B lf you already have at least two or three, 
this does not buy you much 

.Only makes an attack marginally harder 

■ 

1 Excessive NS records cause other 
problems (and adds more potentially 
outdated / vulnerable nameservers) 
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Pfck nameserver more random 

'Old days: prefer nameserver with shortest 
TTL 

.New ways: Add some fuzz 
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^Hardening infrastructure 

queries 

Before accepting NS records or A records 
of nameservers, ask at least two 
different nameservers. 

Before accepting glue records or additional 
data, independently verify these with 
new queries. 

(extra work is only needed once, then we use 
k caching - minimum impact) 
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^xelerance 

' The 0x20 defense (Paul Vixie) 



1 



DNS Question: bogusl2345.www.paypal.com? 
Option flags: RD 



j 
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■fxelerance 

The 0x20 defense (Paul Vixie) 



DNS Question: bogusl2345.www.paypal.com? 
Option flags: RD 



1 

i 



DNS Query ID: 54321 

DNS Question: bOGusl2345. WwW.pAYpaL.Corn 
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The 0x20 defense (Paul Vixie) 



i 



1 

DNS Query ID: 54321 

DNS Question: bOGusl2345.WwW.pAYpaL.Com 


QUESTION SECTION 

Query ID: 54321 

Question: BoGUsl2345.wWW.pAYPal.cOM 

ANSWER SECTION 

AUTHORITY SECTION 
bogusi2345.www.paypal.com NS 
www.paypal.com 




ADDITIONAL SECTION 
www.paypal.com A 1.2.3.4 
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le 0x20 defense (Paul Vixie) 

"You don't need "Td-CaNAdaTRuSt.cOm" 
when you can get ".CoM" 

.Fails completely for the root (".") 
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ouble Fast Flux protection 



■Draft-bambenek-doubleflux suggests: 

I 
1 

Replacing the TTL's of NS and A records 
of NS records with TTL=72 hours. 

1 Llimit Registrar changes to once per 72h 

j Recursors and clients should drop NS or A 
of NS with TTL < 12 
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•§— The inevitable: 

Fix recursive nameservers 

RFC 5452 "Measures for Making DNS 
More Resilient against Forged Answers" 

draft-wijngaards-dnsext-resolver-side- 
mitigation 

draft-vixie-dnsext-0x20 



1 
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*§. 



The real solution 



DNSSEC 
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*§. 



What is DNSSEC? 



■Authenticate (non)existence of data within 
a zone 

■Create a path of trust between zones 

■ 

: Sign and preload the root (".") key 
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*§. 



Traditional DNS 



L 

The root (".") 



xelerance.com 
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Add a public key to zone 













DNSKEY 




The root ("." 






xelerance.conr 
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■fxelerance 

*Sign zone with private key 



The root {"."] 



— ► .com 



xelerance.com 
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^'xelerance 

- Gi\ 



ive hash(pubkey) to parent 



The root (".")- 



— »> .com 



— * xelerance.com 



J 



H*SH(KEY) 
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*§. 



Rinse and Repeat 



DNSKEY 



The root (".")- 



HASHiKtt) 



— ►■ xelerance.com 
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New DNS Record types 


■ DNSKEY 

RRSIG 
. NSEC 

■ 


Public key 

Signature RRset 

"Clever" Record 
denial of existence 


NSEC3 


"Super Clever" 
Record stealthy 
denial of existence 


-JDS 


Delegation Signer r. 
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•& 

^ 



DNSSEC answers can be: 



"SECURE 
! INSECURE 
■BOGUS 
"UNKNOWN 



Validated with key 
Validated but no key 
validation failed 
ServFail etc 
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•§. 



DNSSEC bits 



■The DO bit (query) DNSSEC (is) OK 
■ The AD bit (answer) Authenticated Data 
■The CD bit (query) Checking Disabled 
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*§. 



New DNSSEC errors 



'Uhm, none. For maximum compatibility. If 
any error happens, return the old 
ServFail. 

■ 
■ 

A validator can then redo the query with 
the CD bit if it wants to see why it failed 
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.et's see some DNSSEC... 



Unlike Adam Laurie and Johnny Long, 

■ 

i: I have no cool Hollywood clip I can show 
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.xelerance.com. 


3600 


IN A 




3600 


RRSIG 




3600 


NSEC 




3600 


RRSIG 


.xelerance.com. 


3600 


IN A 




3600 


RRSIG 




3600 


NSEC 




3600 


RRSIG 


d. xelerance.com. 


3600 


IN A 




3600 


RRSIG 




3600 


NSEC 




3600 


RRSIG 



calendar.xelerance.com. 3600 



IN A 



193.110.157.17 

A 5 3 3600 20090314165933 { 

20090212165933 16352 xelerance.com. 

0hgclaigYWLdUYtl3xQRjCNtdlel_taQClsXp[ . . . ] ) 

bugs.xelerance.com. A RRSIG NSEC 

NSEC 5 3 3600 20090314165933 ( 

20090212165933 16352 xelerance.com. 

H5Cr4Z8ovjW81fwCCHBv0i2fiD3zX25NDAth[ . . . ] ) 

193.110.157.129 

A 5 3 3600 20090314165933 { 

20090212165933 16352 xelerance.com. 

dmWVWxzkYXQvzxWwCNwH3jdG™qwQE5PHFPR[ . . . ] ) 

build.xelerance.com. A RRSIG NSEC 

NSEC 5 3 3600 20090314165933 ( 

20090212165933 16352 xelerance.com. 

NLTif8GabVKXmtnWKUtIAGkHD5dPr+yGhAgM[ . . . ] ) 

193.110.157.194 

A 5 3 3600 20090314165933 { 

20090212165933 16352 xelerance.com. 

nEQp0j6e2aAT+B76jlHedHqIKy6+PwIlbB4s[ . . . ] ) 

calendar.xelerance.com. A RRSIG NSEC 

NSEC 5 3 3600 20090314165933 ( 

20090212165933 16352 xelerance.com. 

Lf k6EoDquybGeDqi7z75O04x3mtFNPpgOwTr[ . . . ] ) 

193.110.157.130 
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«» DiG 9.6.0al «» +multiline +dnssec -t ds nic.cz (ai93.110.157. 136 
-»HEADER«- opcode: QUERY, status: NOERROR, id: 44991 
flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 7, ADDITIONAL: 1 
OPT PSEUDOSECTION: 

EDNS: version: 0, flags: do; udp: 4096 
QUESTION SECTION: 

IN DS 



;mc.cz. 

ANSWER SECTION: 
nic.cz. 

nic.cz. 



;; AUTHORITY SECTION: 

cz. 

cz. 

cz. 

cz. 

cz. 

cz. 

cz. 



445 IN DS 59916 5 1 { 

144130216E45C4EC2BB8595E817916E8B060D87B ) 
445 IN DS 27979 5 1 ( 

FF11E740A0254EC63C738A47E52ABF3AD91D8C43 ) 
445 IN RRSIG DS 5 2 1800 20090314003628 ( 

20090212003628 4092 cz. 

c4p82mdTbbydVihi9HP8f8klqN0nWYf JemdAF7Zk78L/[ . . . ] ) I 



16645 


IN 


NS 


d 


ns 


nic 


cz. 




16645 


IN 


NS 


f 


ns 


nic 


cz. 




16645 


IN 


NS 


a 


ns 


nic 


cz. 




16645 


IN 


NS 


c 


ns 


nic 


cz. 




16645 


IN 


NS 


e 


ns 


nic 


cz. 




16645 


IN 


NS 


b 


ns 


nic 


cz. 




16645 


IN 


RRSIG NS 5 1 18000 


20090313023545 



( 

20090211023545 4092 cz. 
xONjUdAHTieDwrVK3En/CmV0oM6JJUTiF5QczRuscHrM[ . . . ] ) I 
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^xelerance 




TJSEC: [ 


Der 


■ ■ 




3600 


NSEC 


SSHFP RRSIG NSEC DN5KEY 




3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 


3600 


RRSIG 


3600 


NSEC 



Denial of existence 






_sip._tcp.xelerance.com. A NS SOA MX TXT NAPT 

NSEC 5 2 3600 20090314165933 { 
_sip._udp.xelerance.com. SRV RRSIG NSEC 
NSEC 5 4 3600 20090314165933 { 
admin.xelerance.com. SRV RRSIG NSEC 
NSEC 5 4 3600 20090314165933 { 
aivd.xelerance.com. A SSHFP RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
conference.aivd.xelerance.com. A RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
monitor.ams.xelerance.com. A RRSIG NSEC 
NSEC 5 4 3600 20090314165933 { 
bofh.xelerance.com. CNAME RRSIG NSEC 
NSEC 5 4 3600 20090314165933 { 
bugs.xelerance.com. A RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
build.xelerance.com. A RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
calendar.xelerance.com. A RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
calender.xelerance.com. A RRSIG NSEC 
NSEC 5 3 3600 20090314165933 { 
cdc.xelerance.com. A RRSIG NSEC 



( •g— NSEC3: denial of 
j| existence with a hack 

B Do not use names, but hashes 
■ For added work, hash X times 
■Now sort the hashes 

■ 

' The validator that gets an NSEC3 record 
back, hashes the QUERY name (x 
times) too and compares 
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^xelerance 

«» DiG 9.6.0al «» -Hnultiline +dnssec -t ns hhhh.gov (9193. lie. 157. 136 
flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1 



!;; AUTHORITY SECTION: 
Igov. 



86381 IN SOA A. GOV. Z0NEEDIT.COM. govcontact.Z0NEEDIT.COM. { 



serial 

refresh {1 hour) 
retry (15 minutes) 
expire {3 weeks) 
minimum {1 day) 



( 



1234994462 

3600 

900 

1814400 

86400 

Bgov. 86381 IN RRSIG SOA 7 1 259200 20090223210103 

B 20090218210103 31802 gov. 

kF4kRKyTIok/tuMdrBB+f smm5+9HYunPGu05292z3+Bl[ . . . ] ) 
HVVS0MCNUB7A79EALVJEH4VN12192C715.gov. 86381 IN NSEC3 1 10 ABAB 0002H1U5Q5HGQCITMSB0 
■QRETCK0N6FLT NS SOA RRSIG DNSKEY NSEC3PARAM 
■VVS0MCNUB7A79EALVJEH4VN12192C715.gov. 86381 IN RRSIG NSEC3 7 2 86400 20090223210103 ( 

20090218210103 31802 gov. 

SazLRlNSEo39Cn0f zWDs/zI8g4qFw5Mm61vZ9neuptfG[ . . . ] ) 
gOYCZA6n rz JDKAkwNlTXLLnf A6k0vyJdf A== ) 
^AJBACCGUPENCE2AAlRNHHLUFHA37G18F.gov. 86381 IN NSEC3 1 10 ABAB AJFCCN9I570TBLMTTFS3 
JH3IREPV0I9TJ NS 

|AJBACCGUPENCE2AAlRNHHLUFHA37G18F.gov. 86381 IN RRSIG NSEC3 7 2 86400 20090223210103 { 

20090218210103 31802 gov. 
0KfqMdW4sV9tvFVH/FY45EPYa53ClqD2px37m2J5a9h8 
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^MSSEC: Use Zone and Key 
Signing keys 





KEY DNSKEY 
£UNb UNSfttY 

xelerance.com 


.com p_ 


HASMlKEY) 



l 



KEY DNSKEY 
ZONE DNSKEY 



— ► xelerance.com 






KEY DNSKEY 
ZONE DNSKEY 
ZONE DNSKEY 

-*■ xelerance.com 



HASMfKE 1 



--v> 
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•HDNSSEC: Key Signing Key 
Rollover 






HASH(KEY) 



KEYD 



DNSKEY 



— #• xeie ranee, com 



KEY DNSKEY 
KEY DNSKEY 
ZONE DNSKEY 



— *- xelerance.com 



— T 

HASH [KEY) 



KEY DNSKEY 
KEY DNSKEY 
ZONE DNSKEY 

xelerance.com 





KEY DNSKEY 
ZONE DNSKEY 

xelerance.com 


1 1 

.com 


HASH(KEY) 
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t •2-~ DNSSEC: Key update 
|[ Triggers or Timers? 

■For DNSSEC: Key update from child to 
parent 

J=or most domains: Any updates via 
Registrant to Registrar to Registry 

1 For some domains: Registrant - Registry 
! communication 

i 

Most common solution will be EPP via 
Registrar. Some by Registry polling 
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www.xelerance.com/dnssec/ 






TLD Production 




1 

■ 
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^xelerance 

DNSSEC Look-aside Verification 



] 





ISC^DRG , XELERANCE.COM 

1) Look for KEY for .com - 



DLV.ISC.ORG 



X— 2) Look for key for xelerance.com 

DLV: xelerance.com.dlv.isc.org 



"H 
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"•Feb 16: https://itar.iana.org/ 



IBWffl.BHlJWmUI.UIJ.IMll.UIIHJIHBf 

View History Bookmarks Tools Help 



] | E|v|.:-..x.gle ~^| ( 



Internet Assigned Numbers Authority 



Protocols About IANA 



Interim Trust Anchor Repository 



IANA provides an Interim Trust Anchor Repository to share the key material required to perform Dl \IIE<: 
verification of signed top-level domains, in lieu of a signed DNS root zone. This is a temporary service until tl 
DNS root zone is signed, at which time the keying material will he placed in the root zone itself, and this se 
will be discontinued. 

What is the repository for? 

The Interim Trust Anchor Repository, or ITAR, act 

been provided by the operators of top-i 

responsible for managing the DNS root zone, and 

trust anchors come from the correct party. The system is considered interim 

deprecated once the DNS root zone itself is signed with DNSSEC. 



Browse the trust anchor repository ► 
Download the trust anchors 



nanism to disseminate "trust anchors" thi 
DNSSEC to secure their zones. IANA is 
existing trust relationships (■:• VH-iify Uio ■: 



What is a ueta? 

This is a preliminary testing version of the service for the community to try. We will take feedback and 
improve the product before it is considered fully production ready. In particular, we appreciate feedback or 
problems that occur, as well as features that could be added to make the service more useful. You can s 
o itartaiana.org . 



Ftooossos and Procedures ► 



a Add a trust anchor ► 
© Revoke a trust ancho 



itar.iana.org ^ FoxyProxy: Patterns -& $ 
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.gov is signed! 



lut DNSSEC for All Top Level .GOV Domains 

^^~ Published: August 29th, 2008 | Category: Security Vulnerabilities 

Last week the Jdget released memoranda M-08-23, titled 

Securing the Federal Government's Domain Name System Infrastructure . The 

document states that all US government top level ,gov domains will use starting 

in January 2009. This is in response to the DNS cache poisoning attack that Dan 
Kaminsky made public a few months ago, 






New Policy 

This memorandum addresses two important issues in following through with the 
existing policy and expanding its scope to address all USG information systems. 

A. The Federal Government will deploy DNSSEC to the top level .gov domain by 
January 2009. The top level .gov domain includes the registrar, registry, and DNS 
server operations. This policy requires that the top level .gov domain will be DNSSEC 
signed and processes to enable secure delegated sub-domains will be developed, 
Signing the to level .gov domain is a critical procedure necessary for broad 
deployment of DNSSEC, increases the utility of DNSSEC, and simplifies lower level 
deployment by agencies, 

B. Your agency must now develop a plan of action and milestones for the deployment 
of DNSSEC to all applicable information systems. Appropriate DNSSEC capabilities 
must be deployed and operational by December 2009. The plan should follow 
recommendations in NIST Special Publication 800-81 "Secure Domain Name System 



•§. 



www.govsecinfo.com 



* The Keys to Deploying DNSSEC: Managing and Meeting Your OMB Domain Mame 

Thursday, March 12, 2009 
Session: 8:30AM - 4:30PM 
Presented by: 



MSSK 



mist 

HarinmH tralitatatA 




DNSSEC Development Coordination Initiative 

The DNSSEC Deployment Initiative works to encourage all sectors to voluntarily adopt security measures 
that will improve security of the internet's naming infrastructure, as part of a global, cooperative effort that 
involves many nations and organizations in the public and private sectors. 
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■fxelerance 

■[ dnssec-conf 

■www.xelerance.com/software/dnssec-conf 

provides key management and dnssec 
configuration for Fedora/RHEL/CentOS 

■ 

: Yum install dnssec-conf 

■ 

dnssec-configure -dnssec=on -dlv=on 
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DNSSEC software 



■Authoritative nameservers: 

Bind - www.isc.org 

NSD - www.nlnetlabs.nl/projects/nsd/ 

Microsoft DNS (support recordtypes, not 
signing) 

■ Recursive validating nameservers: 
Bind - www.isc.org/bind/ 
Unbound - www.unbound.net 
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config-system-dnssec 



■ DN55EC Configuration 


D Enable DNSSEC validation 

Enabe DNSSEC Lookaside Verification(DLV) 






| dlv.isc.org. 




1 B*='p 1 


$ Cancel 1 1 


^OK 
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TODO: Integration 



'Integrate DNSSEC resolverwith Network 
Manager 

■ 

■Use DNS caching infrastructure via DHCP 
obtained DNS servers, but: 

Validate all crypto ourselves on the 
endnode 
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ccNSO survey Nov 2007 



'If you have not implemented DNSSEC, are 
you planning to implement it? 




■YES 85% 
■ NO 10% 
□Unsure 6% 
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ccNSO survey Nov 2007 



■|f you have not implemented DNSSEC, 
when are you planning to implement it? 






35 
30 
25 

20 

15 
10 























































□ Percent 

















































Within 1 year 2 years 



3 years No set timeline 
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Conclusions (1) 



Update your nameservers, or place them behind new 
nameservers. 

Look into more software then just Bind 

Unbound, PowerDNS recursor 

Take a fresh look at your deployment, even when using 
firewalls and NAT. DNS will go through those. 

Ditch DNS captive portals and broken DSL routers 



i 
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Conclusions (2) 
Prepare for DNSSEC 



Tell your vendor[*] you require DNSSEC validation on 
your laptop using a DHCP obtained DNS caching 
server as forwarder. 

[*] If you use Linux/BSD/OSX, why have you not 
installed/configured/enabled it yet? 
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Questions? 

(feel free to test with nssec.xelerance.com) 




lack Hat Briefin 



Why DNSCURVE sucks 



■There is no formal specification nor formal implementation, just proof of 
concept code 

i Encrypts and protects TRANSPORT of dns data not data INTEGRITY itself 

Everyone has to bypass dns caches (or blindly trust them). 

■Causes massive increase in DNS traffic 

■Type overloading of NS records with long crypto keysas names (HACK) 

1 Uses patent encumbered Elliptic Curve cryptography 

! Uses Bernstein's specifically picked homegrown elliptic curve 

[ No cipher or algorithm migration path if the curve falls over 

Uses 95% more CPU (on each query instead of once on a signer machine) 

i Provides no partial deployment support (Secure Entry Points) 

I still need to punch him in the face for qmail 
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